NVIDIA SCADA

导言

GPUDirect Storage 已经能让 NVMe 和 GPU Memory 直接 DMA，为什么 NVIDIA 还要再做一套 SCADA？答案藏在“谁在运行时才知道下一块数据在哪里”这个问题里。

cuFile 适合由 CPU 或上层运行时提交已经成形的文件 I/O；图遍历、GNN 采样和磁盘型向量索引却可能让数十万个 GPU 线程各自发现下一个 offset。SCADA（SCaled Accelerated Data Access）试图把这些细粒度、数据依赖型请求留在 GPU 内核中：先经过 HBM 软件缓存与请求合并，再交给可信服务器访问本地或远端 NVMe。

一句话判断：SCADA 改变的首先是存储控制路径，其次才是数据路径。 它不是 GDS 的新名字，也还不是一个可直接下载部署的通用产品。公开论文已经证明 GPU-initiated storage 的基本机制，2024—2026 年的演讲和硬件演示展示了 SCADA 的扩展方向；但 API、部署要求和端到端生产数据仍处于有限公开阶段。

本文基于截至 2026 年 8 月 28 日可获得的 NVIDIA、OCP、FMS、Micron、ASPLOS 和 VLDB 一手材料。若只想先看最有信息量的原始资料，可以从下面四组开始：

1. OCP 2024：视频：Making a GPU into a Data Access Engine；配套幻灯片。这是 SCADA 名称、适用边界、客户端/服务器架构和早期性能数据最集中的公开材料。
2. GTC 2025：Speed-of-Light Data Movement Between Storage and the GPU。适合区分 GDS、cuObject 与 SCADA，并理解训练、推理、GNN 和向量检索的访问粒度。
3. FMS 2025：Advancing Memory and Storage Architectures for Next-Gen AI Workloads。给出了 SCADA Client、Data Service、uNVMe Driver、控制路径和数据路径的组件图。该 PDF 由 FMS 公开托管且被 Micron 官方文章直接引用，但页面仍带有限制传播标记，本文只链接和概括，不转载页面。
4. GTC 2026：GPU Access to Unbounded Dataset Sizes Breaks Open Document Ingestion and Search。官方页面同时提供视频、AI transcript 和 PDF 按钮，PDF 可能要求登录免费的 NVIDIA Developer Program；内容覆盖最新服务器架构、SCADA 向量索引实验和 Storage-Next。

先把名字说准

NVIDIA 当前文档把 SCADA 定义为一种 GPU 直接发起并控制存储操作的 Storage I/O Architecture，目标是来自大量 GPU 线程的高吞吐、小于 4 KB 的细粒度 NVMe 访问；部署由 GPU 侧 Client Library 和管理 NVMe 的 Server Daemon 组成。Nsight Systems User Guide 已经提供 --enable scada_metrics 采集接口，这比演讲中的概念图更接近真实软件边界。

但“GPU 控制存储”不应理解成 CPU 从此彻底消失。公开 FMS 材料仍让 Host Process 负责 Buffer Registration 与 Housekeeping；2026 年 NVIDIA 官方文章也说明，特权组件会在 Setup 阶段配置应用与获准存储之间的保护关系。NVIDIA Storage-Next 文章 给出的安全原则是：追求速度的用户态部分留在 Trusted Computing Base 之外，由单独的特权组件建立并保护访问边界。

因此更准确的说法是：

• CPU 退出每次 I/O 的热路径，不再替每个 GPU 线程生成请求、处理完成和同步内核；
• CPU 或其他特权组件仍负责慢路径，包括初始化、内存登记、权限配置、映射和后台维护；
• 数据服务端掌握存储所有权，不让不可信的应用 Kernel 任意改写 NVMe Queue 或其他租户的数据。

不要与工业控制 SCADA 混淆

这里的 SCADA 是 NVIDIA 的 SCaled Accelerated Data Access，与工业领域的 Supervisory Control and Data Acquisition 没有关系。检索时最好同时加入 NVIDIA、GPU-initiated storage 或演讲编号。

GDS 为什么还不够

NVIDIA GPUDirect Storage 文档说明，GDS 的核心价值是让存储与 GPU Memory 直接 DMA，避免把数据先搬到 Host Bounce Buffer。它解决的是“数据怎样走得更直接”。

SCADA 面对的是另一个问题：如果下一次读什么只能由正在运行的 GPU 线程发现，谁来及时发起 I/O？

假设 GPU 正在遍历图。线程先读到节点 u，计算后才知道应该访问邻居 v 的 Feature。把这个请求交回 CPU 会引入以下开销：

1. GPU 把 miss 或 next-offset 告诉 CPU；
2. CPU 聚合请求，执行文件系统或 NVMe 提交；
3. 数据进入 GPU Memory；
4. CPU 再通知 GPU 恢复后续 Kernel 或阶段。

一次这样的往返并不致命，十万级线程反复这样做才是问题。CPU 的线程数、系统调用和 GPU/CPU 同步无法匹配 GPU 产生随机请求的速率；若改成预读大块数据，又会把没有用到的字节一起搬进来，形成 I/O Amplification。

两种技术的边界可以这样理解：

维度	GPUDirect Storage / cuFile	SCADA
请求发起者	通常是 CPU 代码、运行时或 CUDA Stream API	GPU Kernel 中的线程，也允许 CPU 发起
请求何时已知	提交前已知 File、Offset、Buffer、Length	运行到数据依赖分支后才知道
典型粒度	大块、可批处理的文件或对象传输	约 4 B—4 KB 的细粒度随机访问
主要优化	去掉 Host Bounce Buffer，提供直接 DMA 数据路径	GPU 发起、HBM Cache、Request Coalescing、高并发 Queue 与可信服务
适合负载	Checkpoint、Model Weight、顺序数据集、已知 Batch	图遍历、GNN Feature、数据依赖型分析、磁盘型 Vector Index
公开成熟度	cuFile/cuObject 有公开文档、API 与部署指南	Limited Access；公开资料以演讲、Profiler 和合作伙伴 POC 为主

OCP 2024 幻灯片给出的选择规则很直接：如果 Batch 可以提前形成，就从 CPU 使用 GDS；如果每个 GPU 线程动态形成自己的请求，才考虑 SCADA。 这不是“旧技术与新技术”的替换关系，而是两个不同控制粒度的工具。

一次 Cache Miss 怎样走

公开材料在 2024、2025 和 2026 年采用过同 GPU Prototype、独立 Storage Server、Grace CPU 与 DPU 等不同部署画法，说明具体拓扑仍在演进。稳定不变的是下面这条逻辑链：

GPU application thread
    -> SCADA client abstraction
    -> HBM software cache
        -> hit: return data inside the running GPU kernel
        -> miss: coalesce and batch requests
    -> control request to trusted SCADA server
    -> GPU-accelerated data service
    -> user-space uNVMe driver / NVMe queues
    -> local PCIe DMA or remote RDMA
    -> target GPU buffer / HBM cache
    -> application thread consumes the result

这条链里的每个对象都解决一个不同瓶颈。

Client 把 I/O 留在 Kernel 中

SCADA Client 被公开演讲描述为 Header-only Library，向上提供接近普通 C++ 数据对象的接口。OCP 2024 材料提到 Contiguous Array 和 Swap；GTC 2025、2026 又出现 mdspan、Key-Value、Graph 与应用定制 Cache。目标不是把 NVMe Submission Queue 原样暴露给算法，而是让 Kernel 用熟悉的数据抽象描述“我要哪一段对象”。

这也意味着 SCADA 不是透明的 Unified Memory。应用或其基础库仍需接入 SCADA 数据抽象，只是 cuGraph/WholeGraph 之上的 GNN Framework 可以尽量保持不变。

HBM Cache 不只减少延迟

数十万个线程可能产生大量重复或相邻请求。HBM Software Cache 同时完成三件事：

• 复用：热点数据直接在 HBM 命中；
• 合并：同一 Cache Line 的请求只向存储发一次；
• 控流：把线程级随机访问变成后端能够承受的 Request Batch。

早期 BaM 论文的消融实验显示，Cache 与 Warp Coalescing 对性能不是小修小补。论文 Figure 8 报告，Naive Cache 相对 No-cache 在 BFS 和 Connected Components 上平均获得 11.9 倍与 12.65 倍加速；进一步利用 Warp Coalescing 和 Reference Reuse 后又有额外收益。BaM 论文证明的是研究原型中的机制价值，不能直接当成当前 SCADA Server 的产品性能。

AutoBatch 把线程并发变成设备并发

GTC 2026 演讲把 Client 与 Server 之间的请求协议称为 AutoBatch Buffer：GPU 侧动态形成 Batch，再提交给 Server 处理。它需要在两个相反目标之间取平衡：

• Batch 太小，Doorbell、Queue 与网络协议开销占比过高；
• Batch 太大，等待聚合会增加 Tail Latency，并拖住同步点前的线程。

这也是 SCADA 更关注 IOPS、Tail Latency、Queue Depth 和 IOPS/W，而不是只看顺序带宽的原因。

Server 收回信任与设备所有权

不可信 GPU Kernel 若能任意构造 NVMe Command、DMA Address 和 LBA，会直接突破进程与租户边界。SCADA 因此把 Client 和 Server 分开：

• Client 追求低开销，运行在用户应用一侧，不进入 Trusted Computing Base；
• Server 运行可信 Data Service，通过批准的 Buffer、LBA Range 和 Data Object 映射处理请求；
• uNVMe Driver 在用户态、GPU 加速的服务中管理 Submission/Completion Queue；
• Control Path 负责权限、元数据和映射，Data Path 通过 PCIe DMA 或网络 RDMA 搬数据。

这不是为了增加一个“微服务层”，而是为了让 GPU-initiated I/O 能进入共享数据中心。2026 年 Micron 对 SCADA 的描述进一步把 Storage Control 放到 Trusted DPU；NVIDIA 同期则把 DOCA 安全栈与 Storage-Next、STX 联系起来。当前公开资料尚不足以证明所有部署都必须使用 DPU，更稳妥的结论是：可信服务角色是架构要求，落在 GPU、Grace CPU、DPU 还是组合系统上取决于发布阶段和平台。

BaM 与 GIDS 奠定了什么

SCADA 不是凭空出现的名字。OCP 2024 幻灯片明确把它放在 BaM 与 GIDS 之后，称为从研究原型走向 Production Stack Trial Integration 的后续工作。

如果要先比较 GPUfs、GDS、BaM、GMT 的通用控制路径与数据路径，以及 BaM、GDS、SPDK 的资源账单，可以先读站内的 GPU-Initiated I/O；本节只保留理解 SCADA 演进所需的 BaM 与 GIDS 证据。

BaM：GPU 直接驱动 NVMe

BaM（Big accelerator Memory）发表于 ASPLOS 2023。它把 GPU Thread 的 Array Access 接到软件 Cache、高吞吐 Queue 与 NVMe Driver，让 GPU 在不依赖 CPU 发起每次 I/O 的情况下访问 SSD。其公开实现包含 bam::array、Cache、GPU/NVMe Queue、Block Microbenchmark 和图算法。

论文报告：

• 四块 Intel Optane SSD 上，BaM 相对 Host-Memory Target 的 BFS 端到端性能基本持平，Connected Components 快 1.49 倍；
• 与同硬件上的 CPU-initiated RAPIDS Data Analytics Path 相比，部分 Query 最多快 5.3 倍；
• 相对把整个图装入 Host DRAM 的方案，论文估算硬件成本最多降低 21.7 倍。

这些数字依赖 A100、PCIe Gen4、Optane、特定图和 Cache 配置。它们证明“GPU 发起 + Cache + 高并发 NVMe Queue”可以成立，不证明任意 SCADA 应用都会更快。

GIDS：把机制接入 GNN Dataloader

GIDS发表于 PVLDB 2024，把 BaM 数据路径接入 DGL GNN Training。它引入 Dynamic Storage Access Accumulator、Constant CPU Buffer 和带 Window Buffering 的 GPU Software Cache，用混合 HBM、Host DRAM 与 SSD 放置改善采样和 Feature Aggregation。

最终论文在单 GPU、TB 级数据集上报告相对当时 DGL Dataloader 最多 582 倍端到端加速；GIDS 代码公开了 Dataloader 与 BaM 依赖。这个极大倍数来自基线在 Out-of-Core 场景中的 Page Fault 与 CPU Bottleneck，不能外推为 SCADA 对所有 GNN Training 的平均提升。

从 BaM 到 GIDS 再到 SCADA，主线并不是“NVMe 变快了”，而是抽象层逐步上移：

BaM: GPU thread -> cache -> raw NVMe
GIDS: GNN dataloader -> hybrid placement -> BaM
SCADA: object-oriented client -> trusted data service -> local/remote storage

性能证据支持到哪里

SCADA 的公开性能材料跨越 Research Prototype、Application Paper 与 Partner Microbenchmark。把它们混成一条“最高可达”数字会失去实验边界。

4 KB：早期单机原型

OCP 2024 幻灯片第 20 页给出的 BaM Block Microbenchmark 在一张 DGX A100 GPU、四到六块 NVMe 上执行 4 KB Random Read：四块 Gen4 Drive 达到约 **6.1 MIOPS、23.2 GB/s，CPU Utilization 为 0%**，已接近 GPU 的 PCIe Gen4 带宽上限。

这说明 GPU 生成与处理 I/O Queue 的速率可以追上多块 SSD；它没有测量 Graph、Vector Search 或 Multi-tenant Server 的端到端延迟。

512 B：PCIe Gen6 扩展演示

Micron 在 SC25 演示中使用 44 块 Micron 9650 PCIe Gen6 SSD、3 张 H100 NVL 96 GB、3 颗 Broadcom PEX90000 Switch，报告 SOL SCADA Workload 达到 230M 512 B Random Read IOPS，并称从 1 到 44 块 SSD 近似线性扩展。Micron 原始测试说明公开了硬件和 Queue Tuning 参数；2026 年更新说明这些 PCIe Gen6 组件已经商业出货，可用于客户 POC。GTC 2026 更新

这里最重要的限定词是 SOL Microbenchmark。它证明 SCADA Stack 能把数百 MIOPS 压到一组 SSD 上，不等于 VectorDB Query、GNN Training 或 Agent Memory Retrieval 已经达到同等应用吞吐。

一个常见的理论上限来自链路带宽：

$$
IOPS_{pin}\approx\frac{B_{PCIe}}{G_{IO}}
$$

若 PCIe Gen6 链路按 100 GB/s、单次访问 512 B 估算：

$$
IOPS_{pin}\approx\frac{100\times10^9}{512}\approx195\text{ MIOPS}
$$

OCP 材料把它取整为约 200 MIOPS/GPU。这个式子只是 Pin Bandwidth Budget；Protocol Overhead、Read/Write Mix、Tail Latency、Cache Miss、SSD Media 与 Queue Contention 都会让实际结果偏离。

大数据集：容量而不是绝对速度

GTC 2026 的 Vector Index Build 初步实验提供了一个更诚实的观察：在较小数据集上，未经优化的 SCADA 方案相对“数据已在 Host Memory”约慢 2.8 倍；数据集扩大 10 倍后，差距缩小到约 2 倍，而同规模已经无法放进 HBM。演讲者明确称这是 Unoptimized Research Work。GTC 2026 视频与 Transcript

这组结果揭示了 SCADA 的真实价值函数：

它未必让能放进内存的问题跑得更快，而是让放不进内存的问题仍能用少量 GPU 运行，并让性能随 Storage IOPS 扩展。

因此评估 SCADA 不能只问“比 DRAM 慢多少”，还要问“纯内存方案需要多少节点、是否能运行、预加载多少未使用数据，以及每单位性能的成本和功耗”。

哪些负载真正适合

SCADA 的适用条件比“AI 访问存储”窄得多。一个负载同时具备以下特征时，收益才可能覆盖软件 Cache、Queue、Server 与集成成本：

• 数据规模无界：工作集无法稳定放入单机 HBM 与 Host DRAM；
• 访问依赖运行时数据：下一次 Offset、Key、Neighbor 或 Vector Node 只能在 GPU Kernel 中决定；
• 粒度小：大致在 4 B—4 KB，若用 64 KB Page 或大块预读会产生显著 Read Amplification；
• 并发极高：有成千上万 GPU Threads 可以用来隐藏百微秒级 Storage Latency；
• 数据访问受限：瓶颈是取数，而不是大规模 Matrix Compute；
• 存在局部性：HBM Cache、Coalescing 或 Application Hint 能减少后端 I/O。

公开资料反复使用以下例子：

• GNN Neighbor Sampling 与 Feature Aggregation；
• BFS、Connected Components 和大图分析；
• 磁盘型 Approximate Nearest Neighbor Index Build/Search；
• 只读取所需 Row/Column 的 Data Analytics；
• 未来的 Key-Value、VectorDB、Dataframe 与 Swap Service。

反过来，下面几类负载通常不应先找 SCADA：

• Checkpoint、Model Weight、连续 Dataset Batch：请求在 Host 已知，优先使用 GDS/cuFile、cuObject 或 NIXL；
• 工作集可放入 HBM：普通 Load/Store 的延迟和编程成本更低；
• 计算密集型 Kernel：Storage Path 不是瓶颈，GPU Thread 还可能被 I/O Polling 占用；
• 请求太少或同步太频繁：并发不足以隐藏 SSD Tail Latency；
• 强依赖 POSIX Filesystem Semantics：公开 SCADA 设计强调 Captive Block Storage 与 Object-specific Abstraction，迁移成本不可忽略。

现在能不能部署

截至 2026 年 8 月，答案应分三层。

1. 研究机制可以复现：BaM 与 GIDS 有开源代码和论文 Artifact，但需要特定 PCIe P2P、Data-center GPU、Raw NVMe、Above 4G Decoding 等环境。BaM 的安装要求不等于正式 SCADA 的最低硬件要求。
2. SCADA Stack 确实存在：Nsight Systems 已公开 SCADA Server Metrics Plugin，默认通过 /tmp/scada_profiler_socket 与 Server 通信；Micron、H3、Broadcom 和 DDN 已披露 POC 或集成工作。
3. 通用开发者产品仍未完全公开：GTC 2026 幻灯片标注 SCADA 为 Limited Access；目前没有找到面向普通开发者的公开 SCADA SDK、API Reference、Installer、Release Notes 或开源 Server Repository。

硬件可购买不等于软件已 GA

Micron 9650、H3 Falcon 6048 与 Broadcom PEX90000 的商业出货，证明 PCIe Gen6 Reference Hardware 可以采购；它不自动意味着 SCADA Software 已 General Availability。做采购或产品规划时，应分别确认 Hardware BOM、SCADA Access、License、支持的 Data Service 与 Security Deployment。

如果要启动 POC，建议先向 NVIDIA 或合作存储厂商确认以下问题：

1. 访问与版本：SCADA Client/Server 如何获得，支持哪些 CUDA、Driver、GPU、Grace/DPU 与 OS 版本？
2. 数据抽象：当前可用的是 Array、Swap、Key-Value、Graph 还是 Vector Index？需要改应用还是只改基础库？
3. 拓扑：Client/Server 能否同 GPU，何时必须独立 Storage GPU、Grace CPU 或 DPU？
4. 设备所有权：是否需要 Captive Raw NVMe，能否与现有 Filesystem、NVMe-oF、RAID 或 Object Store 共存？
5. 安全边界：谁登记 Buffer、分配 LBA、验证 Request，Compromised Client 能造成什么影响？
6. 实测指标：4 KB 与 512 B IOPS、P50/P99/P999 Latency、Cache Hit Rate、Batch Size、Queue Depth、SM Occupancy 和 CPU/DPU Utilization 分别是多少？
7. 端到端结果：与“数据已在 DRAM”、GDS、Memory Mapping 和 Scale-out Memory Baseline 相比，应用吞吐、成本与功耗如何？

Nsight Systems 的公开入口至少给出了一条验证路径：

nsys profile --enable scada_metrics <target-application>

# 降低采样频率，并指定 SCADA Server 的 Unix Domain Socket
nsys profile \
  --enable scada_metrics,--sampling-frequency=100,--socket-path=/path/to/scada.sock \
  <target-application>

Profiler 会从 Server 动态读取 Metrics Schema，因此不同 Server Configuration 暴露的 Counter 与 Histogram 可能不同。官方文档给出的例子包括 Received Buffer、Average Latency、Commands per Buffer 与 Latency Distribution。POC 应优先观察尾延迟和每个 Buffer 的命令数，而不只看总带宽。

资料怎样阅读

SCADA 的公开叙事在两年内变化很快。按下面的顺序阅读，比直接从 2026 年最新材料开始更容易建立稳定边界。

顺序	资料	最值得看	证据边界
1	BaM 论文，ASPLOS 2023	Cache、Queue、GPU NVMe Driver、Graph/Data Analytics 实验	研究原型，不是 SCADA 产品
2	GIDS 论文，PVLDB 2024	GNN Dataloader、Hybrid Placement、TB 级应用结果	单 GPU 与特定 DGL Baseline
3	OCP 2024 视频与幻灯片	SCADA 定义、Client/Server、GDS 边界、4 KB Microbenchmark	Functional Prototype 阶段
4	GTC 2025 视频	GDS/cuObject/SCADA Taxonomy，训练与推理访问模式	演讲 Transcript 为 AI 生成，关键数字需回看视频
5	FMS 2025 PDF	Data Service、uNVMe、Control/Data Protocol、Security	公开托管但带传播限制标记，不宜转载页面
6	Micron SC25 测试	230M IOPS 的完整 Hardware BOM 与 Tuning	512 B Random-read Microbenchmark
7	GTC 2026 视频与 PDF	Vector Index、AutoBatch、Storage Server、Limited Access 状态	早期、未优化应用实验
8	Nsight Systems SCADA Metrics	可操作的 Server Profiler、Socket 与 Metrics Schema	不是完整部署或 API 文档

另有一份 NVIDIA 与 IBM 的 ISC 2025 幻灯片，第 21 页把 GDS、cuFile、cuObject 与 SCADA 放在同一张 Storage Technology Map 中，并给出 Gen5 uNVMe Driver 达 98 MIOPS 的演讲数字。它适合补充 Ecosystem 视角，但不足以替代上面的主资料。

结论

回到最初的问题：有了 GPUDirect Storage，为什么还需要 SCADA？

因为 Direct Data Path 不等于 Direct Control Path。GDS 能让数据绕过 Host DRAM，却不自动解决十万级 GPU Threads 在 Kernel 内动态发现、发起并等待小 I/O 的问题。SCADA 把 HBM Cache、Request Aggregation、GPU-side NVMe Queue 和可信 Data Service 组合成一个新的 Programming Model，目标是把 Storage 变成 GPU 可以主动驱动的下一级 Memory Tier。

现在可以确认三点：

• GPU-initiated Fine-grained Storage Access 已被 BaM、GIDS 和多代 Microbenchmark 证明可行；
• SCADA 已从论文原型推进到有 Nsight Profiling、PCIe Gen6 Reference Platform 和厂商合作的有限访问栈；
• 它最有价值的场景不是替换所有 GDS，而是让“无法放进内存、又不能提前形成 Batch”的数据访问型应用继续扩展。

还不能确认的是：公开材料尚不足以给出通用 SCADA SDK 的安装步骤、稳定 API、支持矩阵、生产安全认证与跨应用平均收益。现阶段更合理的动作不是按 230M IOPS 直接采购，而是拿一个真正满足细粒度、数据依赖、高并发条件的 Workload 做 POC，并把 End-to-end Throughput、Tail Latency、IOPS/W、IOPS/$ 和 Integration Cost 放在同一张账本里。

参考资料

• NVIDIA, As AI Increases Demands on Memory, Storage Steps Up, 2026.
• NVIDIA, GPUDirect Storage Documentation.
• NVIDIA, Nsight Systems User Guide: SCADA Metrics Profiling.
• CJ Newburn and Vikram Sharma Mailthody, Making a GPU into a Data Access Engine, OCP Global Summit 2024.
• CJ Newburn, Prashant Prabhu, and Vikram Sharma Mailthody, Speed-of-Light Data Movement Between Storage and the GPU, GTC 2025.
• Vikram Sharma Mailthody, Advancing Memory and Storage Architectures for Next-Gen AI Workloads, FMS 2025.
• CJ Newburn, Corey Nolet, and Vikram Sharma Mailthody, GPU Access to Unbounded Dataset Sizes Breaks Open Document Ingestion and Search, GTC 2026.
• Zaid Qureshi et al., GPU-Initiated On-Demand High-Throughput Storage Access in the BaM System Architecture, ASPLOS 2023; code.
• Jeongmin Brian Park et al., Accelerating Sampling and Aggregation Operations in GNN Frameworks with GPU Initiated Direct Storage Accesses, PVLDB 2024; code.
• Micron, SC25 Performance Breakthrough: 230M IOPS in a Single Server, 2025.